Why are you using this instead of check_existing_association? There are cases where ExtendedByDataModelId could be null:

• If data model type is BaseLIF or SourceSchema, then I think the ExtendedByDataModelId will always be null.
• If the data model type is OrgLIF or PartnerLIF then the ExtendedByDataModelId may or may not be null.

I didn't like that it was an 'or' condition in check_existing_association. I felt we should be able to determine what value the ExtendedByDataModelId should be prior to invoking the method.

I've been having a hard time trying to determine how we could reverse engineer the ExtendedByDataModelId of the association. I think what I said in my other comment is true that for the OrgLIF and PartnerLIF, these are the cases where ExtendedByDataModelId of the association will not be null:

1. The entity/attribute itself is an Extension and has ExtendedByDataModelId non-null.
2. Someone used "+ Existing" to create an association in their OrgLIF or PartnerLIF that does not exist in BaseLIF.

That 2nd case is difficult to discern. The only thing I can think of to prove this is:

1. If the Association has Extension=true, then ExtendedByDataModelId=anchor_data_model_id.

But we're trying to fetch the Association based off of this info, so we don't know yet whether or not it's an extension. I guess if you wanted, you could fetch the Association with the 'or' condition and then check if Extension=true and if it does then check that ExtendedByDataModelId=anchor_data_model_id.

Sounds like from your last paragraph we can determine existance by the query:

!Extension AND ExtendedByDM == AnchorDM
OR 
Extension AND ExtendedByDM == Null

I think that's backwards. And to summarize the full context:
If data_model_type == BaseLIF or SourceSchema, then Extension is always False and ExtendedByDataModelId is always null.
If data_model_type == OrgLIF or PartnerLIF, then...

!Extension AND ExtendedByDM == Null
OR 
Extension AND ExtendedByDM == AnchorDM

🙃 I coded it the way you just noted , but then wrote my comment backwards.

If the data model is BaseLIF or SourceSchema, then the association's extended_by_data_model_id should equal null always.
If the data model is OrgLIF or PartnerLIF, then the association's extended_by_data_model_id should be non-null if:

1. The entity/attribute itself is an Extension and has ExtendedByDataModelId non-null.
2. Someone used "+ Existing" to create an association in their OrgLIF or PartnerLIF that does not exist in BaseLIF.

I don't think we need to try to calculate which of these situations we're in though. I think it's okay to just always check for the association with extended_by_data_model_id = null or anchor_data_model_id, which is what I'm trying to suggest in my other comment when I say that I think you should use the check_entity_association method instead of the check_entity_association_strict method. Same for checking the entity-attribute association.

I was revising this, and realized that using check_entity_association could fail if there is an match with a null extended_by_data_model_id and a extended_by_data_model_id with a value in the database. Might need to call it twice.

I think the logic we've discussed in the comment thread for check_entity_association_strict will address this. If I'm understanding correctly, I think you can either call it twice or include an OR operator in the check.